Persistant client state in a hypertext transfer protocol based client-server system

ABSTRACT

A method and apparatus for transferring state information between a server computer system and a client computer system. In one embodiment of the method, an http client requests a file, such as an HTML document, on an http server, and the http server transmits the file to the http client. In addition, the http server transmits a state object, which describes certain state information, to the http client. The http client stores the state object, and will typically send the state object back to the http server when making later requests for files on the http server. In a typical embodiment, the state object includes a domain attribute which specifies a domain or network address, and the state object is transmitted from the http client to a server only when the http client makes an http request to the server and the server is within the domain. In one embodiment, the apparatus includes a processor and memory and a computer readable medium which stores program instructions. In the case of the client system, the instructions specify operations such as receiving and storing the state information; in the case of the server system, the instructions specify operations such as sending the state information to a client system.

This application is a divisional of U.S. patent application Ser. No.08/540,342, filed Oct. 6, 1995, which is now U.S. Pat. No. 5,774,670,which issued on Jun. 30,1998.

FIELD OF THE INVENTION

This invention relates to communication in a client-server computersystems. Specifically, the invention relates to client-server computersystems in which a server can send state information to a client and theclient stores the state information for later retransmissions back tothe server.

BACKGROUND OF THE INVENTION

An important use of computers is the transfer of information over anetwork. Currently, the largest computer network in existence is theInterNet. The InterNet is a worldwide interconnection of computernetworks that communicate using a common protocol. Millions ofcomputers, from low end personal computers to high-end super computersare coupled to the InterNet.

The InterNet grew out of work funded in the 1960s by the U.S. DefenseDepartment's Advanced Research Projects Agency. For a long time,InterNet was used by researchers in universities and nationallaboratories to share information. As the existence of the InterNetbecame more widely known, many users outside of the academic/researchcommunity (e.g., employees of large corporations) started to useInterNet to carry electronic mail.

In 1989, a new type of information system known as the World-Wide-Web("the Web") was introduced to the InterNet. Early development of the Webtook place at CERN, the European Particle Physics Laboratory. The Web isa wide-area hypermedia information retrieval system aimed to give wideaccess to a large universe of documents. At that time, the Web was knownto and used by the academic/research community only. There was no easilyavailable tool which allows a technically untrained person to access theWeb.

In 1993, researchers at the National Center for SupercomputingApplications (NCSA) released a Web browser called "Mosiac" thatimplemented a graphical user interface (GUI). Mosiac's graphical userinterface was simple to learn yet powerful. The Mosiac browser allows auser to retrieve documents from the World-Wide-Web using simplepoint-and-click commands. Because the user does not have to betechnically trained and the browser is pleasant to use, it has thepotential of opening up the InterNet to the masses.

The architecture of the Web follows a conventional client-server model.The terms "client" and "server" are used to refer to a computer'sgeneral role as a requester of data (the client) or provider of data(the server). Under the Web environment, Web browsers reside in clientsand Web documents reside in servers. Web clients and Web serverscommunicate using a protocol called "HyperText Transfer Protocol"(HTTP). A browser opens a connection to a server and initiates a requestfor a document. The server delivers the requested document, typically inthe form of a text document coded in a standard Hypertext MarkupLanguage (HTML) format, and when the connection is closed in the aboveinteraction, the server serves a passive role, i.e., it accepts commandsfrom the client and cannot request the client to perform any action.

The communication model under the conventional Web environment providesa very limited level of interaction between clients and servers. In manysystems, increasing the level of interaction between components in thesystems often makes the systems more robust, but increasing theinteraction increases the complexity of the interaction and typicallyslows the rate of the interaction. Thus, the conventional Webenvironment provides less complex, faster interactions because of theWeb's level of interaction between clients and servers.

In the conventional Web environment, clients do not retain informationof a session after the session is closed. In many systems, the abilityto retain information after the systems become inactive is crucial tothe functioning of the systems. Thus, it is desirable to allow clientsto have this ability.

SUMMARY OF THE INVENTION

The present invention involves a client-server system on a network inwhich a server can send state information to a client and the clientstores the state information. The stored state information can later besent back to the server at appropriate times. In this manner, the stateof a client can be maintained in the client-server system where no stateinherently exists in such a system.

One embodiment of the present invention is a network system forcommunicating documents containing information such as text and one ormore images. The system comprises a first computer (i.e., a server)capable of sending such documents over a network such as the InterNet.The system also has a second computer (i.e., a client) which can requestthese documents or files from the server. After the requested documentsare received, the client can display the documents. In accordance withthe present invention, the server can send state information to theclient when a document is sent. The client then stores the stateinformation, which is typically in the form of a state object. In asubsequent request for documents to the server, the client can send thestored state information to the server.

In an embodiment of the invention, the server uses a hypertext transferprotocol ("http") to communicate over the network with clients; suchclients also communicate with the server using the hypertext transferprotocol. This server and these clients are referred to as an httpserver and http clients respectively. The server typically will includea server processor and a memory and a computer readable medium, such asa magnetic ("hard disk") or optical mass storage device, and thecomputer readable medium of the server contains computer programinstructions for transmitting the file from the server system to theclient system and for transmitting the state object to the clientsystem. The client typically will include a client processor and amemory and a computer readable medium, such as a magnetic or opticalmass storage device, and the computer readable medium of the clientcontains computer program instructions for receiving the state object,which specifies the state information, from the server and for storingthe state object at the client. The state object, in a typicalembodiment, will include a name attribute, such as a domain attribute.

One of the applications of the present invention is an on-line shoppingsystem. A customer can browse information delivered by a merchant serverusing a browser running on a client. The customer can also selectproducts to be placed in a virtual shopping basket. The server thensends state information related to the selected products to the browseron the client for storage. When the customer wants to purchase theproducts in the virtual shopping basket, the browser sends thecorresponding state information to a specified check-out Web page forprocessing.

Another application of the present invention is an "on-line" informationservice, such as a newspaper's Web server which includes articles orother information from the newspaper's subscription services. In oneexample, a newspaper or publishing company may have several differentpublications, each requiring a separate subscription fee which maydiffer among the different publications. A user of the informationservice may browse the different publications by making http requests,from the client's/user's computer system, to the publisher's Web serverwhich responds with the requested publication and state informationspecifying the user's identification, and other subscription information(e.g., user registration and billing information) which allows the userto view the contents of the publication; this information is typicallyprovided by the user at least once in a conventional log-on process.Thereafter, this information is included in the state information whichis exchanged between the client and the server in the process of theinvention. Accordingly, when the user, during the browsing process,desires to view another publication (e.g., from the same or differentpublisher) this state information will be transmitted back to the Webserver to provide the necessary subscription information (therebyentitling the user to view the publication) without requiring the userto re-enter the necessary subscription information. In this manner, auser may browse from publication to publication on the Web server or adifferent Web server in the domain without having to re-enter, whenseeking a new publication, the necessary subscription information.

These and other features of the present invention will be disclosed inthe following description of the invention together with theaccompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The objects, features, and advantages of the present invention will beapparent from the following detailed description of the preferredembodiment of the invention with references to the following drawings.

FIG. 1A is a pictorial diagram of a computer network used in the presentinvention.

FIG. 1B shows a computer network containing a client system and a serversystem.

FIG. 2 illustrates the retrieval of remote text and images and theirintegration in a document.

FIG. 3A shows an example of an HTML document which can be processed bythe browser of the present invention.

FIG. 3B shows the integrated document corresponding to the HTML documentof FIG. 3A as it would appear on a display screen of a client computer.

FIG. 4 shows schematically the flow of information between a client anda server in accordance with the present invention.

FIG. 5 is a flow chart showing the operation of a merchant system of thepresent invention.

FIG. 6 shows a computer system that could be used to run the browser ofthe present invention.

DETAILED DESCRIPTION

Methods and apparatuses for maintaining state information in aclient-server based computer network system are disclosed. The followingdescription is presented to enable any person skilled in the art to makeand use the invention. For purposes of explanation, specificnomenclature is set forth to provide a thorough understanding of thepresent invention. However, it will be apparent to one skilled in theart that these specific details are not required to practice the presentinvention. Descriptions of specific applications are provided only asexamples. Various modifications to the preferred embodiments will bereadily apparent to those skilled in the art, and the general principlesdefined herein may be applied to other embodiments and applicationswithout departing from the spirit and scope of the invention. Thus, thepresent invention is not intended to be limited to the embodimentsshown, but is to be accorded the widest scope consistent with theprinciples and features disclosed herein.

Prior to describing the present invention, some introductory material isexplained, including explanations concerning client-server computing,InterNet addresses, URL's and browsing of the Web.

Client-Server Computing

FIG. 1A illustrates a conceptual diagram of a computer network 100, suchas the InterNet. Computer network 100 comprises small computers (such ascomputers 102, 104, 106, 108, 110 and 112) and large computers, such ascomputers A and B, commonly used as servers. In general, small computersare "personal computers" or workstations and are the sites at which ahuman user operates the computer to make requests for data from othercomputers or servers on the network. Usually, the requested data residesin large computers. In this scenario, small computers are clients andthe large computers are servers. In this specification, the terms"client" and "server" are used to refer to a computer's general role asa requester of data (client) or provider of data (server). In general,the size of a computer or the resources associated with it do notpreclude the computer's ability to act as a client or a server. Further,each computer may request data in one transaction and provide data inanother transaction, thus changing the computer's role from client toserver, or vice versa.

A client, such as computer 102, may request a file from server A. Sincecomputer 102 is directly connected to server A through a local areanetwork, this request would not normally result in a transfer of dataover what is shown as the "network" of FIG. 1. The "network" of FIG. 1represents the InterNet which is an interconnection of networks. Adifferent request from computer 102 may be for a file that resides inserver B. In this case, the data is transferred from server B throughthe network to server A and, finally, to computer 102. The distancebetween servers A and B may be very long, e.g. across continents, orvery short, e.g., within the same city. Further, in traversing thenetwork the data may be transferred through several intermediate serversand many routing devices, such as bridges and routers.

The World-Wide-Web ("The Web") uses the client-server model tocommunicate information between clients and servers. Web Servers arecoupled to the InterNet and respond to document requests from Webclients. Web clients (also known as Web "browsers") are programs thatallow a user to simply access Web documents located on Web Servers.

FIG. 1B shows, in more detail, an example of a client-server systeminterconnected through the InterNet 100. In this example, a remoteserver system 122 is interconnected through the InterNet to clientsystem 120. The client system 120 includes conventional components suchas a processor 124, memory 125 (e.g. RAM), a bus 126 which couples theprocessor 124 and memory 125, a mass storage device 127 (e.g. a magnetichard disk or an optical storage disk) coupled to the processor andmemory through an I/O controller 128 and a network interface 129, suchas a conventional modem. The server system 122 also includesconventional components such as a processor 134, memory 135 (e.g. RAM),a bus 136 which couples the processor 134 and memory 135, a mass storagedevice 137 (e.g. a magnetic or optical disk) coupled to the processor134 and memory 135 through an I/O controller 138 and a network interface139, such as a conventional modem. It will be appreciated from thedescription below that the present invention may be implemented insoftware which is stored as executable instructions on a computerreadable medium on the client and server systems, such as mass storagedevices 127 and 137 respectively, or in memories 125 and 135respectively.

InterNet Addresses

As discussed in the background, the InterNet consists of a worldwidecomputer network that communicates using well defined protocol known asthe InterNet Protocol (IP). Computer systems that are directly connectedto the InterNet each have an unique InterNet address. An InterNetaddress consists of four numbers where each number is less than 256. Thefour numbers of an InterNet address are commonly written out separatedby periods such as 192.101.0.3

To simplify InterNet addressing, the "Domain Name System" was created.The domain name system allows users to access InterNet resources with asimpler alphanumeric naming system. An InterNet Domain name consists ofa series of alphanumeric names separated by periods. For example, thename "drizzle.stanford.edu" is the name for a computer in the physicsdepartment at Stanford University. Read from left to right, each namedefines a subset of the name immediately to the right. In this example,"drizzle" is the name of a workstation in the "stanford" domain.Furthermore, "stanford" is a subset of the "edu" domain. When a domainname is used, the computer accesses a "Domain Name Server" to obtain theexplicit four number InterNet address.

Uniform Resource Locators

To further define the addresses of resources on the InterNet, theUniform Resource Locator system was created. A Uniform Resource Locator(URL) is a descriptor that specifically defines a type of InterNetresource and its location. URLs have the following format:

resource₋₋ type://domain.address/path₋₋ name

Where "resource₋₋ type" defines the type of internet resource. Webdocuments are identified by the resource type "http" which indicatesthat the hypertext transfer protocol should be used to access thedocument. Other resource types include "ftp" (file transmissionprotocol) and "telnet". The "domain.address" defines the domain nameaddress of the computer that the /resource is located on. Finally, the"path₋₋ name" defines a directory path within the file system of theserver that identifies the resource. The right most name on the pathname portion is usually the name of an actual file. Web pages areidentified by the resource type "http". By convention, most Web pagesend with the suffix ".html" that suggests the file is a HyperText MarkupLanguage document.

An example of a URL for a Web document is:

http://info.cern.ch/hypertext/Datasources/WWW/Geographical.html

This URL indicates that by using the HTTP (Web) protocol to reach aserver called "info.cern.ch", there is a directory"hypertext/Datasources/WWW" that contains a hypertext document named"Geographical.html." Resources on the Internet are uniquely addressableby their URL.

Browsing the World-Wide-Web

To access an initial Web document, the user enters the URL for a Webdocument into a Web browser program. The Web browser then sends an httprequest to the server that has the Web document using the URL. The Webserver responds to the http request by sending the requested HTTP objectto the client. In most cases, the HTTP object is an plain text (ASCII)document containing text (in ASCII) that is written in HyperText MarkupLanguage (HTML). The HTML document usually contains hyperlinks to otherWeb documents. The Web browser displays the HTML document on the screenfor the user and the hyperlinks to other Web documents are emphasized insome fashion such that the user can selected the hyperlink.

FIG. 2 illustrates the retrieval of remote text and images and theirintegration in a Web page by a client computer 130. In FIG. 2, server Acontains a text document coded in a standard HTML format. Server Bcontains an image file called Image 1 and server C contains anotherimage file called Image 2. Each of these servers is remotely locatedfrom the other servers and the client 130. The transfer of data is viathe Internet. It should be appreciated that the text and image filescould be located in the same server which is remote from client 130.

FIG. 3A shows an example of an HTML document. FIG. 3B shows thecorresponding integrated document (Web page) as it would appear on adisplay screen of a client computer. The first line of the document inFIG. 3A reads "<title> Distributed Image Loading Example</title>." Inthis case, the tags <title> and </title> are HTML delimiterscorresponding to the beginning and ending, respectively, of text that isdesignated as the title of the HTML document. The title could be usedfor various purposes, such as listing of the document in anautomatically generated index.

The second line of the HTML document of FIG. 3A reads "<h1> DistributedImage Loading Example </h1>" The <h1> and </h1> are HTML delimiters fora header that is to be displayed in a largest font. The browser softwarerunning on the client computer 130 interprets the header tags and thusdisplays the text between the header tags in a largest font size on theclient's display screen.

After the title and header, the HTML document of FIG. 3A contains thetext "One of the major features . . . capability". At the end of thetext paragraph is another HTML tag shown as <p>. This is a tagindicating the end of a paragraph.

To continue with the second paragraph of the HTML document, the textreads "This document . . . this image: <IMG align=middlesrc="http://www.su.se/SUlogo.gif"> was obtained . . . ". The text inangle brackets defines an image to be placed in the text. Specifically,the "IMG" tag indicates that an image is being defined. The"align=middle" tag indicates that the image should be aligned in themiddle of the current line of text. Finally, "src=" tag indicates thatthe source image file can be located using the URL"http://www.su.se/SUlogo.gif".

The line continues with the phrase "from the <Ahref="http://www.su.se/index.html"> University of Stockholm</A> Thisphrase defines "University of Stockholm" as a link to another Webdocument. Specifically, the "A" tag defines the beginning of a link. The"href=" tag defines that the link is to a Web page that can be locatedusing the URL "http://www.su.se/index.html" Next, the text "Universityof Stockholm" is the text that will be the link. Finally, the "/A" tagdefines the end of the link definition. As illustrated in FIG. 3B, thetext "University of Stockholm" is displayed with underlining thatindicates it is a link to another document. If the user selects theunderlined text "University of Stockholm", then the browser will sendout a http request for the Web page at the URL address"http://www.su.se/index.html".

It can be seen from the above example that the HTML document containsall information a browser needs for displaying a Web page. Thus, theonly responsibility of a Web server is to provide the requesteddocument, and there is no need for the server to request a client to doanything else. However, this role of a server also limits the utility ofthe Web environment.

Adding State Information to the HyperText Transfer Protocol

The present invention provides an extension to the prior art HTTPprotocol. Using the teachings of the present invention, when a serverresponds to an http request by returning an HTTP object to a client, theserver may also send a piece of state information that the client systemwill store. In an embodiment of the present invention, the stateinformation is referred to as a "cookie". Included in the stateinformation (the cookie) is a description of a range of URLs for whichthat state information should be repeated back to. Thus, when the clientsystem sends future HTTP requests to servers that fall within the rangeof defined URLs, the requests will include a transmittal of the currentvalue of the state object. By adding the ability to transfer stateinformation back and forth, Web servers can then play an active role intransactions between clients and servers. The term state object is alsoused herein to refer to the state information.

FIG. 4 is a drawing showing schematically the flow of informationbetween a client system and a server system. At a time indicated bynumeral 172, the client system sends an http request to the Web server.In response to the http request, the server returns an HTML documenttogether with a header, which is typically separate from the HTMLdocuments, at a time indicated by numeral 174. The header may containone or more cookies. Upon receiving the HTML document and the header,the client system displays an HTML document on the screen and stores thecookies in a memory such as a storage medium. The client may switch andwork on other tasks, or may be shut down completely. This is indicatedby a dash line 176. At a time indicated by numeral 178, the clientsystem may access a Web server that is specified in the received cookie,such that the client system transmits the cookies to the server, thusproviding state information about the client system to the serversystem.

This extension to the http protocol provides a powerful new tool whichenables a large number of new types of applications to be written for aWeb-based environment. Examples of new applications include on-lineshopping that stores information about items currently selected byconsumers, for-fee on-line services that can send back registrationinformation and thus free users from retyping a user-id on nextconnection, and Web sites that can store per-user preferences on theclient system and have the client supply those preferences every timethe site is later accessed.

Server Behavior

A particular embodiment of the state information is described below inorder to provide an example according to the present invention. It willbe appreciated that alternative formats may be used in accordance withthe principles of the present invention. As stated above, the extensionto the HTTP protocol adds a new piece of state information to the HTTPheader as part of an HTTP response from a Web server. Typically, thestate information is generated by a common gateway interface ("CGI")script. The state information is stored by the receiving client systemin the form of a "cookie list" for later use. The syntax of the newdata, in one embodiment, is:

Set-Cookie: NAME=VALUE; expires=DATE; path=PATH;

domain=DOMAIN₋₋ NAME; secure

The capitalized terms can be set by the server system. The firstattribute is "NAME=VALUE". This attribute serves to identify a cookie.The "NAME" attribute is a name for the cookie. The "NAME" attribute isthe only required attribute on the "Set-Cookie" header in oneembodiment. The "VALUE" is a value assigned to the previously definedname. The "VALUE" is a string of characters excluding, in oneembodiment, semicolon, comma, and white spaces. If there is a need toplace these characters in the VALUE, standard encoding methods, such asURL's type % XX encoding, can be used.

The "expires" attribute specifies a data string that defines the validlife time of the corresponding cookie. Once the expiration date has beenreached, the cookie will no longer be stored in the client system. Thus,the client system will no longer respond to Web servers with the cookie.Many coding schemes for designating time can be used. In a preferredembodiment, the "expires" attribute is formatted as: Wdy, DD-Mon-YYHH:MM:SS GMT In the this format, "Wdy" designates the day of a week,"DD-Mon-YY" designates the day, month and year, and "HH:MM:SS GMT"designates the hour, minute and second, in GMT time zone. Note that the"expires" attribute lets a client know when it is safe to purge acookie, however, the client is not required to delete the cookie. If anexpires attribute is not provided by the server, then the cookiesexpires when the user's session ends. This can be implemented by storingthe cookie only in volatile memory.

The "domain=DOMAIN₋₋ NAME" attribute defines a domain for which thecookie is valid. The domain attribute is usually set using the domainname of the sending Web server. Client systems examine the domainattribute when making later http requests. If the server that the clientsystem is accessing falls within the defined DOMAIN₋₋ NAME, then thecookie may be sent to the server when making the http request. (The"path" must also be examined as will be explained later.) When a serversystem falls within the defined DOMAIN₋₋ NAME, this is referred to as a"tail match." Note that a domain name that defines a subset of a domainis deemed to match a larger enclosing domain. For example, the hostnames "anvil.acme.com" and "shipping.crate.acme.com" fall within the"acme.com" domain.

Only hosts within the specified domain can set a cookie for a domain.The value of the "domain" attribute must have at least two periods inthem to prevent accepting values of the form ".com" and ".edu". If nodomain name is specified, then the default value of the "domain"attribute is the domain name of the server that generated the cookieheader.

The "path" attribute is used to specify a subset of file systemdirectories in a domain for which the cookie is valid. If a cookie hasalready passed "domain" matching, then the path name of the URL for arequested document is compared with the "path" attribute. If there is amatch, the cookie is considered valid and is sent along with the httprequest. All the characters of the defined path must match, howeverthere may be additional characters on the path name. Thus, furtherdefined subdirectories will match a path to the parent director. Forexample, the path "/foo" would match "/foo/bar", "/foo/bar.html", andevert "/foobar", but "/foo" will not match the path "/". Note that thepath "/" is the most general path since it will match any path. If nopath is specified when a cookie is created, then the default path willbe the same path as the document that was sent with the header whichcontains the cookie.

The last element of the cookie definition is the optional label of"secure." If a cookie is marked "secure," then the cookie will only beretransmitted if there is a secure communication channel to the serversystem. In a preferred embodiment of the present invention, this meansthat the cookie will only be sent to HTTPS servers. (HTTP over SSL) Ifthe "secure" attribute is not specified, a cookie is considered safe tobe sent over unsecured channels.

The defined extension to the HTTP protocol allows multiple setcookieheaders to be issued in a single HTTP response. Each set-cookie headershould follow the conventions of the above described format.

Client Behavior

As previously described, when a client receives a set-cookie command ina header, the client system stores the cookie in some type of storage.In order not to place too much burden on client systems, each clientsystem is expected to be able to store only a limited number of cookies.In one embodiment, the storage requirements for the client systems are:

(1) 300 total cookies;

(2) 4 kilobytes per cookie; and

(2) 20 cookies per server or domain (note that this rule treatscompletely specified hosts and domains which are different as separateentities, and each entity has a 20 cookies limitation).

Servers should not expect clients to be able to exceed these limits.When the 300 total cookies or the 20 cookie per server limit isexceeded, clients may delete the least recently used cookie even if thecookie's "expires" time has not passed.

If a cookie is received that matches the "NAME", "domain" and "path"attributes of a previously received cookie, then the previously receivedcookie will be overwritten. Using this technique, it is possible for aserver to delete a cookie previously sent to a client. Specifically, aserver that wishes to delete a previous cookie sends a cookie having"expires" time which is in the past that matches the "NAME", "domain"and "path" attributes of cookie to be deleted. Since the new overwrittencookie contains a expires time that has passed, the cookie will bedeleted by the client system. Note "NAME", "domain" and "path"attributes of the expired cookie must match exactly those of the validcookie. Since a system must be within the domain that is specified inthe domain attribute, it is difficult for any server other than theoriginator of a cookie to delete or change a cookie.

When a client system that implements the present invention wishes tosend an http request to a particular Web server, the client system firstexamines its cookie list to see if the cookie list contains any matchingcookies that need to be sent to the particular Web server. Specifically,before the client sends an http request to a Web server, the clientcompares the URL of the requested Web document against all of the storedcookies. If any of the cookies in the cookie list matches the requestedURL then information containing the name/value pairs of the matchingcookies will be sent along with the HTTP request. The format of the lineis:

Cookie: NAME1=value1; NAME2=value2; . . .

When a client sends cookies to a server, all cookies with a morespecific path mapping should be sent before cookies with less specificpath mappings. For example, a cookie "name1=foo" with a path mapping of"/bar" should be sent before a cookie "name2=foo2" with a path mappingof "/" if they are both to be sent since the path "/bar" is morespecific than the global matching path "/".

Paths having a higher-level value do not override more specific pathmappings. If there are multiple matches for a given cookie name, butwith separate paths, all the matching cookies will be sent. Thus, boththe cookie "name=foo" with a path mapping of "/bar" and the cookie"name=foo" with a path mapping of "/" should be sent since they havedifferent path names.

Some clients access Web servers on the Internet through firewall systemsthat are designed to prevent unwanted Internet traffic from affecting alocal area network coupled to the Internet. Firewall systems oftenimplement "proxy servers" that filter traffic to and from the Internet.It is important that proxy servers not cache Set-cookie commands whencaching HTTP information. Thus, if a proxy server receives a responsethat contains a Set-cookie header, the proxy server should immediatelypropagate the Set-cookie header to the client. Similarly, if a clientsystem request contains a "Cookie:" header, the cookie header should beforwarded through a proxy even if a conditional "If-modified-since"request is being made.

To further describe the present invention, the following examplesdescribe a set of Web transactions operating in accordance with thepresent invention:

EXAMPLE 1

A client system requests a Web document from the Web server"telemarking.acme.com" and receives in response:

Set-Cookie: CUSTOMER=WILE₋₋ E₋₋ COYOTE; path=/;

expires=Wednesday, Nov. 9, 1999 23:12:40

The client system stores this cookie in a local (client-side) storageunit (e.g. mass storage 127 or memory 125). Since no domain name wasspecifically identified, the domain will be set to"telemarking.acme.com" since that is the domain name of the server thatgenerated the cookie. When the client later makes an http request for adocument in any path (since the path is "/") of a server system in thetelemarking.acme.com domain, the client sends:

Cookie: CUSTOMER=WILE₋₋ E₋₋ COYOTE

Assuming the client system makes another request to thetelemarking.acme.com domain, the client might receive another cookiefrom the server such as:

Set-Cookie: PART₋₋ NUMBER=ROCKET₋₋ LAUNCHER;

path=/

The client will locally store this additional cookie. Again, no domainname was identified, such that the default domain,"telemarking.acme.com" will be stored. Now, if the client makes yetanother request to the "telemarking.acme.com" domain, the client willsend all the cookies it has for that domain. Specifically, the clientsends:

Cookie: CUSTOMER=WILE₋₋ E₋₋ COYOTE;

PART₋₋ NUMBER=ROCKET₋₋ LAUNCHER

Assuming, the client continues transactions with the"telemarking.acme.com" server, it may receive the following cookie fromthe server:

Set-Cookie: SHIPPING=FEDEX; path=/foo

Then, if the client requests a document in path "/" on the"telemarking.acme.com" server, the client will send two cookies as stateinformation:

Cookie: CUSTOMER=WILE₋₋ E₋₋ E₋₋ COYOTE;

PART₋₋ NUMBER-ROCKET₋₋ LAUNCHER

Note that the cookie SHIPPING=FEDEX was not sent because the path "/"does not match the path "/foo". On the other hand, when the clientrequests a document on the "telemarking.acme.com" server in path "/foo"on this server, then the client will send three cookies as stateinformation;

Cookie: CUSTOMER=WILE₋₋ E₋₋ COYOTE;

PART₋₋ NUMBER=ROCKET₋₋ LAUNCHER;

SHIPPING=FEDEX

EXAMPLE 2

Assume that all of the transactions of Example 1 have been cleared. Aclient system then requests a Web document from the Web server"telemarking.acme.com" and receives in response:

Set Cookie: PART₋₋ NUMBER=ROCKET₋₋ LAUNCHER₋₋ 1;

path=/

The client stores this cookie in a local (client-side) storage unit.Since no domain name was specifically identified, the domain will be setto "telemarking.acme.com". When the client later makes a request to adocument in any path of a system in the telemarking.acme.com domain, theclient sends back the following data as information:

Cookie: PART₋₋ NUMBER=ROCKET₋₋ LAUNCHER₋₋ 1

Assuming the client continues to access the "telemarking.acme.com"server, the client may later receive from the server:

Set-Cookie: PART₋₋ NUMBER=RIDING₋₋ ROCKET₋₋ 23;

path=/ammo

The new cookie has the same name (PART₋₋ NUMBER) as an old cookie storedon the client system. Note that the old cookie is not overwritten sincethe new cookie has a different path attribute. Now, if the client makesa request for a document in the path "/ammo" on thetelemarking.acme.com" server, the client should send the following twocookies as state information:

Cookie: PART₋₋ NUMBER=RIDING₋₋ ROCKET₋₋ 23;

PART₋₋ NUMBER=ROCKET₋₋ LAUNCHER₋₋ 1

Both cookies are sent since the path of the requested document ("/ammo")matches both the "/" path of the first cookie and the "/ammo" path ofthe second cookie. Note that the cookie PART₋₋ NUMBER=RIDING₋₋ ROCKET₋₋23 is sent first since it has a more specific path ("/ammo") than theglobal path ("/") associated with the cookie PART₋₋ NUMBER=ROCKET₋₋LAUNCHER₋₋ 1.

An On-line Shopping System Application

To illustrate one possible use of the state information system of thepresent invention, an implementation of an on-line shopping system willbe described. The on-line shopping system allows customers to shop inone or more stores that are implemented as Web servers on the Internet.A customer can browse information on the Web servers that describeproducts available from the stores. When a desired product is found, theuser can place the product into a "virtual shopping basket." The virtualshopping basket is implemented as a set of cookies that are sent to theclient computer system and stored on the client computer system. Atcheck-out time, the customer pays for the selected products using sometype of payment system such as a credit card. After payment is received,the on-line shopping system notifies the stores to ship the selectedproducts to the customer. FIG. 5 is a flow chart showing the operationof the merchant system during an on-line shopping "trip" by a customer.The customer can run a browser on a client computer system, such ascomputer system 140 shown in FIG. 6 or client system 120 shown in FIG.1B The computer system 140 of FIG. 6 includes a display device 142 (suchas a monitor), a display screen 144, a cabinet 146 (which enclosescomponents typically found in a computer, such as CPU, RAM, ROM, videocard, hard drive, sound card, serial ports, etc.), a keyboard 148, amouse 150, and a modem 152. Mouse 150 have one or more buttons, such asbuttons 154. The computer needs to have some type of communicationdevice such as that Modem 152 allows computer system 140 to be connectedtb the Internet. Other possible communication devices include ethernetnetwork cards.

The customer uses Web browser software to access an on-line "merchant"server that is operated by a merchant having products to sell. Thismerchant server is a server computer system such as server system 122shown in FIG. 1B. Specifically, the browser software sends an httprequest for the home Web page of a merchant Web server (step 212). Themerchant Web server responds to the request with an HTML document thatis displayed by the browser (step 214). The home Web page containsinformation about the merchant and its products (e.g., shoes, hats,shirts, etc.). The home Web page can implement a set of linked Web pagesthat describe the products that are available from the merchant. Eachproduct may be associated with its own HTML document that fullydescribes the product. Products can be described using text, images,sounds, video clips, and any other communication form supported by Webbrowsers. The user can continue browsing through Web pages of themerchant server by repeating steps 212, 214, and 215.

After browsing through the Web pages provided by the server, thecustomer may select a product (step 216) by, for example, "clicking" (inthe conventional manner) on an image of a product that causes thebrowser to request a Web page that fully describes the product. If thecustomer wishes to buy shoes from the merchant, the customer could clickon a "buy it" button. The merchant server then sends an HTML formdocument that requests the customer to send necessary details for thepurchase (step 218). For example, the customer may select a quantity, adesired style, and size of the product as requested by the formdocument. The browser then sends a POST command under HTTP, whichtransmits the data entered into the form to the merchant server (step222). The data on the submitted form (e.g., quantity, size, style, etc.)is analyzed by the server and the transaction is processed. The serverthen generates a synthetic page and sends it to the browser running onthe client system. This synthetic page preferably contains a thank younote along with confirmation information. Cookies containing informationdescribing the selected product are also sent at this time (step 224).

The browser software running on the client system stores the cookiesdescribing the selected products within the client computer system (step226). The stored cookies include an identification of the contents of avirtual shopping basket that contains the products selected by theconsumer. In an embodiment of the present invention, the cookies arestored in a file located in a storage medium (such as a hard disk) ofclient computer system 140.

The time interval for storing the cookies that describe the selectedproducts can be set to any desired length. In one embodiment of thepresent invention, the cookies are deleted when the customer exits fromthe browser. This can be accomplished by not setting the "expires"attribute of the product description cookies. In another embodiment ofthe present invention, the cookies are kept valid (prior to theirexpiration) even after the customer exits from the browser and turns offcomputer 140. This can be accomplished by setting the "expires"attribute of the product description cookies to a later date.

After selecting a product, the customer may do additional shopping(e.g., buy a hat) from the same store or other stores (step 228). Inthis case, steps 212, 214, 215, 216, 218, 222, 224 and 226 need to beperformed for the additional products. Each selection of a product instep 222 will result in the transmission of a cookie from the server tothe client, which cookie identifies the selected product. The customermay also exit from the merchant system at any time.

When the customer desires to buy the products, the customer accesses alink that identifies a "check-out" Web page. The check-out Web pagecauses the browser to send all the product description cookies (230).Thus, the check-out Web page empties out the virtual shopping basket.The merchant server generates a total bill for all the products in thevirtual shopping basket. The server may then request billing information(e.g., credit card number) and shipping (e.g., address) information fromthe customer using a form. In a preferred embodiment the transaction ofcredit card information is transmitted using a secure medium. Thetransaction server then performs a real-time credit card authorization.Once the transaction is authorized, transaction server sends messages toindividual merchants to fulfill the order (step 240).

Other functions could be added to the above described merchant system.For example, several persons could use the same browser for shopping. Inthis case, the browser identifies the person doing the shopping, andassigns product description cookies to the appropriate person. Thus,each person would have their own virtual shopping basket.

The invention has been described with reference to specific exemplaryembodiments thereof and various modifications and changes may be madethereto without departing from the broad spirit and scope of theinvention. The specification and drawings are, accordingly, to beregarded in an illustrative rather than a restrictive sense; theinvention is limited only by the following claims.

What is claimed is:
 1. A method for subscribing to an on-lineinformation service, said method comprising the steps of:requesting afirst information service from an http server; and transmitting a stateobject from a client computer system to said http server, said stateobject being stored on said client system and specifying userinformation to said http server.
 2. A method as in claim 1 wherein saidstate object specifies user identification information and billinginformation.
 3. A method as in claim 1 further comprising:requesting asecond information service from said http server or an alternative httpserver; transmitting said object to said http server or said alternativehttp server.
 4. A method as in claim 3 wherein a user of said on-lineinformation service browses from said first information service to saidsecond information service without having to enter user information. 5.A method of claim 3 wherein said user information comprises subscriptioninformation required by a first publisher of said first informationservice.
 6. A method as in claim 5 wherein said user informationcomprises subscription information required by a second publisher ofsaid second information service.